As is known in the art, a “simulation model” or more simply a “model” is a specialized software program used to simulate a real world scenario. A large class of simulation models simulate scenarios which are comprised of individual tasks the antecedent conditions for which involve the allocation of one or more resources which may be used or needed by multiple tasks. The resources are thus sometimes referred to as “common resources.”
For example, a simulation of the construction of a building might consider carpenters and plumbers to be resources. The simulation might be constructed so that many individual carpentry and plumbing tasks that are involved in constructing the building are each associated with an allocation request. Each request would describe a number of carpenters or plumbers needed to perform the associated task. The simulation proceeds only when available resources are allocated to a request, allowing the task associated with the request to be performed. Since the outstanding requests all potentially compete for some common set of available resources, there is often resource contention among the requests.
In such simulation models, the means by which resource allocation requests are submitted and selectively granted to the requesting tasks is often referred to as the “resource allocation strategy” for the simulation. Resource allocation also occurs in simulations of processes such as manufacturing processes, where manufacturing tools and materials might be construed as resources.
Many simulation models contain mechanisms for simulating resource allocation. These mechanisms may be provided by the simulation modeling system in which the model is constructed, or they may be constructed as part of the simulation model itself, perhaps making use of an extensibility mechanism provided by the simulation modeling system. It is also possible to construct a resource allocation mechanism using generic, non-simulation specific programming techniques, as might be done when a simulation model is built directly using an ordinary programming language.
The SimProcess and SimScript and the Foresight simulation modeling systems, for example, have resource allocation mechanisms built in, which can be invoked when constructing a simulation model. These systems as well as the Ptolemyll system also have extensibility mechanisms which allow the simulation modeler to provide additional logic in conjunction with the simulation model itself in order to implement resource allocation mechanisms.
Whether implemented directly or by extension, in this prior art, it is typically possible to name sets of resources, describe those resource capacities, and to provide schedules which describe how a resource capacity may change over time. It may also be possible to replenish a resource, increasing its capacity during the course of simulation. Another common prior art characteristic is the ability to associate a priority value with each individual resource allocation request. In the presence of competing outstanding requests, the allocation strategy then allocates requests in order of descending priority. Using only resource capacities and request priorities as provided in the prior art, however, it is difficult, impractical or sometimes even impossible to simulate a large class of resource allocation strategies. In particular, allocation strategies which make reference to one or more attributes other than resource levels or priorities of the task for which the allocation is required, can be extremely difficult or impossible to simulate.
Consider again a building construction simulation. It may be the case that the building contains a location, say Room A, which is physically too small to accommodate more than 3 workers of any type at any time. Therefore, the resource allocation strategy should only allocate resources to Room A if it doing so does not exceed the 3 worker limit. Given only the task attribute of priority supported by the prior art, this constraint is difficult to enforce in a simulation. An attempt to do so using just task priority would seem to entail that the priority be modified dynamically during the course of the simulation, while the request was still pending and unallocated. When Room A was full of workers, for instance, the priorities of remaining requests would have to be adjusted so that all requests in locations other than Room A would have greater priority than all outstanding Room A requests. But when some task completes in Room A, making it possible to allocate some more resource to Room A, some outstanding Room A request would have to have its priority adjusted again so that Room A could receive another allocation without having to wait for all the work in other rooms to complete first. So task priority alone is incapable of expressing the limit of resources which can be allocated to a specific location.
A similar allocation problem arises when there is a pool of resources available, say five (5) plumbers, but the simulation calls for the plumbers to behave as if they were two core crews of two (2) plumbers each, with 1 floating plumber who can participate in either crew at any time. The prospect of dynamically changing request priorities and possibly altering resource capacities dynamically is equally intractable in this case.